The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. As the number of basic applications, and the media which it is possible to combine, increases, so will the number of services offered to the end users, giving rise to a new generation of personalised, rich multimedia communication services. The IMS is defined in the 3GPP Specification 23.228.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signaling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
IMS relies on Internet Protocol (IP) as a transport technology. Using IP for voice communications, however, presents some challenges, especially in the mobile community where Voice Over IP (VoIP) enabled packet switched (PS) bearers may not always be available. To allow operators to start offering IMS-based services while voice enabled PS-bearers are being built out, the industry has developed solutions that use existing Circuit Switched (CS) networks to access IMS services. These solutions are referred to as IMS Centralized Services (ICS). ICS is also the name of the Work Item in 3GPP Release 8 addressing these matters (IP Multimedia System (IMS) centralized services (Release 8), 3GPP TS 23.292 V8.0.0).
A functional entity in an IMS network is a Service Centralization and Continuity Application Server (SCC AS), which is an application based in a user's home network IMS Application. The SCC AS provides functionality required to enable IMS Centralized Services. The SCC AS is inserted in a session path using originating and terminating Initial Filter Criteria (iFCs) and configured such that it is the first AS in an originating iFC chain and the last AS in a terminating iFC chain.
User Equipment (UE) typically communicates with the SCC AS for service control using the Gm reference point. In come circumstances, using a Gm reference point may not be possible (e.g. when using GERAN and the GERAN does not support DTM). In this case, a service control signaling path is handed over to I1. 3GPP TS 23.292, section 7.8 describes the procedure for signaling path handover from Gm to I1 when Gm is lost or not available. The UE sends the handover request to the SCC AS over I1 and the SCC AS is informed that it should now use I1 instead of Gm for controlling the ongoing session with the UE.
When a handover from Gm to I1 is required, the handover request should be routed from the UE over I1 to the same SCC AS that was previously handling the session over Gm. Suppose, for example, that Unstructured Supplementary Service Data (USSD) is used to communicate over I1. Using current methods, a Home Location Register (HLR) can be statically configured with an E.164 number for the ICS service code for a range of subscribers. This E.164 number can represent the actual SCC AS or a Representative AS (see IP Multimedia Subsystem (IMS); Stage 2 (Release 8), 3GPP TS 23.228 V8.3.0) that performs dynamic allocation of users to an SCC AS. However, routing over Gm is not synchronized with routing over I1. No solution exists to allow the UE to route a request over I1 to the same SCC AS over Gm. There is therefore no guarantee that in the event of a handover from Gm to I1,the handover request over I1 will be routed to the same SCC AS that was previously handling the session over Gm, and so the handover may fail. This problem exists not only for the signaling path handover from Gm to I1,but also in the case of service continuity where a service transfer is made from a Packet Switched (PS) to a Circuit Switched (CS) access.